Network Working Group B. Manning (Rice University) INTERNET DRAFT R. Colella (NIST) 26 Nov, 1992 DNS NSAP RRs Status of This Memo This memo refines the approch taken in RFC 1348, updating the processing methods for encoding of NSAP addresses for the Internet community. Discussion and suggestions for improvement are requested. This document is an Internet Draft. Internet Drafts are working documents of the Internet Engineering Task Force (IETF), its Areas, and its Working Groups. Note that other groups may also distribute working documents as Internet Drafts). Internet Drafts are draft documents valid for a maximum of six months. Internet Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet Drafts as reference material or to cite them other than as a "working draft" or "work in progress." Please check the I-D abstract listing contained in each Internet Draft directory to learn the current status of this or any other Internet Draft. It is intended that this document will be submitted to the IESG for consideration as a standards document. Distribution of this document is unlimited. Abstract The Internet is moving towards the deployment of an OSI lower layers infrastructure. This infrastructure comprises the connectionless network protocol (CLNP) and supporting routing protocols. Also required as part of this infrastructure is support in the DNS for mapping between names and NSAP addresses. This document redefines the format of two new Resource Records for the Domain Name System, as defined in RFC 1348. This format may be used with any OSI NSAP address format. Expiration: April 14, 1993 [Page 1] INTERNET-DRAFT DNS NSAP RRs 26 Nov, 1992 Contents 1 Introduction . . . . . . . . . . . . . . . . . . . . . . . 6 2 Background . . . . . . . . . . . . . . . . . . . . . . . . 6 3 Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 4 Structure of NSAPs . . . . . . . . . . . . . . . . . . . . 6 5 NSAP RR specification . . . . . . . . . . . . . . . . . . . 6 5.1 The NSAP RR . . . . . . . . . . . . . . . . . . . . . . . . 6 5.2 The NSAP-PTR RR . . . . . . . . . . . . . . . . . . . . . . 6 6 DNS Operation for NSAPs . . . . . . . . . . . . . . . . . . 6 7 Examples . . . . . . . . . . . . . . . . . . . . . . . . . 6 8 Security Considerations . . . . . . . . . . . . . . . . . 6 9 References . . . . . . . . . . . . . . . . . . . . . . . . 6 10 Author's Address . . . . . . . . . . . . . . . . . . . . . 6 A Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 6 B. Manning (Rice University) [Page 2] INTERNET-DRAFT DNS NSAP RRs 26 Nov, 1992 1 Introduction The Internet is moving towards the deployment of an OSI lower layers infrastructure. This infrastructure comprises the connectionless network protocol (CLNP) [ISO8473] and supporting routing protocols. Also required as part of this infrastructure is support in the Domain Name System (DNS) [RFC1034, RFC1035] for mapping between DNS names and OSI Network Service Access Point (NSAP) addresses [ISO8348Ad2] [Note: NSAP and NSAP address are used interchangeably throughout this memo]. This memo redefines the format of two new Resource Records (RRs) for the DNS, as defined in RFC 1348. This format may be used with any OSI NSAP format. This memo assumes that the reader is familiar with the DNS. Some familiarity with NSAPs is useful; see [RFC1237] or [ISO8348Ad2] for additional information. 2 Background The reason for defining DNS mappings for NSAPs is to support CLNP in the Internet. Debugging with CLNP ping and traceroute is becoming more difficult with only numeric NSAPs as the scale of deployment increases. Current debugging is supported by maintaining and exchanging a configuration file with name/NSAP mappings similar in function to hosts.txt. This suffers from the lack of a central coordinator for this file and also from the perspective of scaling. The former is the most serious short-term problem. Scaling of a hosts.txt-like solution has well-known long-term scaling difficiencies. A second reason for this work is the proposal to use CLNP as a replacement for IP: "TCP and UDP with Bigger Addresses (TUBA), A Simple Proposal for Internet Addressing and Routing" [RFC1347]. Should this proposal be selected, the DNS must be capable of supporting CLNP addresses. 3 Scope The RRs defined in this paper support all known NSAP formats. In addition, the RRs support the notion of a custom-defined NSAP format. There are several ways in which an NSAP can be defined. To illustrate this feature, examples in this memo will assume that the Internet obtained an AFI from ISO and defined a fixed-field NSAP format. As a point of reference, there is a distinction between registration and publication of addresses. For IP addresses, the IANA is the root registration authority and the DNS a publication method. For NSAPs, ISO8348/Ad2 is the root registration authority and the DNS is being proposed as a publication method. B. Manning (Rice University) [Page 3] INTERNET-DRAFT DNS NSAP RRs 26 Nov, 1992 4 Structure of NSAPs NSAPs are hierarchically structured to allow distributed administration and efficient routing. Distributed administration permits subdelegated addressing authorities to, as allowed by the delegator, further structure the portion of the NSAP space under their delegated control. Accomodation of this distributed authority requires flexibility in the DNS representation of NSAPs, allowing sub- authorities to represent the substructure they define, if any, in the DNS as well as the NSAP values themselves. While all NSAP structures currently known to be in use in the Internet have fixed field sizes (e.g., [RFC1237, IPTAG-92-23-PB660], some NSAP formats defined in ISO 8348Ad2 define one of the fields as variable-sized. These formats are still parsable, since the total NSAP length is known and there is, at most, one variable-sized field. These formats are accomodated in this document, even though there is no current requirement. The notation is fully described in Section 5.2, "The NSAP_PTR RR" and the processing in Section 6, "DNS Operation for NSAPs." For the purposes of this memo, NSAPs can be thought of as a tree of identifiers. The root of the tree is defined in Addendum 2 to ISO8348 [ISO8348Ad2], and has as its immediately registered subordinates the one-octet Authority and Format Identifiers (AFIs) defined there. The size of subsequently-defined fields depends on which branch of the tree is taken. The depth of the tree varies according to the authority responsible for defining subsequent fields. An example is the authority under which US GOSIP defines NSAPs [GOSIPv2FT]. Under the AFI of 47, NIST (National Institute of Standards and Technology) obtained a value of 0005 (the AFI of 47 defines the next field as being two octets consisting of four BCD digits from the International Code Designator space [ISO6523]). NIST defined the subsequent fields in [GOSIPv2FT].The field immediately following 0005 is a format identifier for the rest of the US GOSIP NSAP structure, with a hex value of 80. Following this is the three-octet field, values for which are allocated to network operators; the registration authority for this field is delegated to GSA (General Services Administration). The last octet of the NSAP is the NSelector (NSel). In practice, the NSAP minus the NSel identifies the CLNP protocol machine on a given system, and the NSel identifies the CLNP user. Since there can be more than on CLNP user (meaning multiple NSel values for a given "base" NSAP), the representation of the NSAP should be CLNP-user independent. TO achive this, an NSel value of zero will be used with all NSAP values stored in the DNS. An NSAP with NSel=0 identifies the network layer itself. It is left to the application retrieving the NSAP to determine the appropriate value to use in that instance of communication. In the event that CLNP is used to support TCP and UDP services, the NSel value used will be the appropriate IP PROTO value as registered with IANA. For "standard" OSI, the selection of NSel values is left as a matter of local administration. Administrators of systems that support support TP0-4 in addition to TCP/UDP will select NSels for use by TP0-4 that do NOT conflict with the IP PROTO vlaues. For the purposes of this memo, we will present NSAPs as a string of "."-separated hex values. This is common usage, not the "+" operator specified in RFC1278. The values correspond to the fields in the NSAP, as defined by the appropriate authority. For example, a printable representation of the first four fields of a US GOSIP NSAP might look like 47.0005.80.005a00 and a full US GOSIP NSAP is 47.0005.80.005a00.0000.1000.0020.00800a123456.01. For more information on US GOSIP NSAPs, see RFC1237 [RFC1237]. Other NSAP formats have different fields and field widths; see the examples in Section 7 and also [IPTAG-92-23-PB660]. B. Manning (Rice University) [Page 4] INTERNET-DRAFT DNS NSAP RRs 26 Nov, 1992 5 NSAP RRs Specification 5.1 The NSAP RR The NSAP RR is defined with mnemonic NSAP and type code 22 (decimal). The NSAP RR has the following format: < owner> < ttl> < class> NSAP < rdata> All fields are required. The < owner> is the DNS name for the system that is addressed by the NSAP in the < rdata> field (see below). The meaning of the < ttl> field is as specified in RFC1034. The format of the NSAP RR is class insensitive. The < rdata> is a complete NSAP address expressed in the dotted hexidecimal notation as described in Section 7. NSAP RR causes no additional section processing. 5.2 the NSAP-PTR RR The NSAP-PTR RR is defined with mnemonic NSAP-PTR and type code 23 (decimal). It's function is analogous to the PTR record used for IP addresses [RFC1035, RFC1103], although the details of how it operates are different. The NSAP-PTR RR has the following format: < owner> < ttl> < class> NSAP-PTR < rdata> All fields are required. The < owner> is a complete NSAP or an NSAP prefix. The octets of the NSAP are in reverse order, with the least significant octet on the left and the AFI octet on the right. The reversal is on an octet boundary. The dotted hexidecimal notation described in Section 7 is used to separate the NSAP fields. The meaning of the < ttl> field is as specified in RFC1034. B. Manning (Rice University) [Page 5] INTERNET-DRAFT DNS NSAP RRs 26 Nov, 1992 The format of the NSAP-PTR RR is class insensitive. The < rdata> field consists of two subfields separated by one or more spaces or tabs. The first subfield is a DNS name that corresponds to the owner of this NSAP prefix. In the case of an incomplete NSAP (i.e., an NSAP prefix), this subfield must name the root with a single ".". The second subfield of < rdata> contains structure information for subsequent fields of the NSAP, to the extent that they are known at this level of the NSAP tree. Strictly speaking, only the size of the next field is required to navigate the DNS NSAP tree. However, for efficiency the NSAP structure information should be included as far up towards the root as possible. The format of this subfield is a set of "."-separated decimal digits representing the sizes of fields subsequent to the NSAP prefix given in the < owner> field. [Should we have a BNF for this?] A trailing "." indicates that the structure information is complete. For leaf entries (i.e., when the < owner> contains a complete NSAP), this subfield must contain a single ".". The NSAP-PTR RR causes no additional section processing. 6 DNS Operation for NSAPs Name-to-NSAP mapping in the DNS using the NSAP RR operates analogously to IP address lookup. A query is generated by the resolver requesting an NSAP RR for a provided DNS name. NSAP-to-name mapping using the NSAP-PTR RR differs from the inverse lookup for IP addresses due to the structure of NSAPs and the requirements this places on the lookup process. The NSAP-to-name scheme operates with minimal a priori knowledge of how NSAPs are structured and operates according to a simple algorithm. Given an NSAP to be resolved, the only a priori information needed is that the first field of all NSAPs is one octet. The basic algorithm operates as follows: 1.build an initial query to read the record associated with the first octet. 2.knowledge of the NSAP structure is not complete, so set (COMPL-KNOW = FALSE). 3.send the query. 4.when the response is returned, if (COMPL-KNOW == TRUE), done. 5.construct a more detailed query with the additional structure information from the response. 6.if the structure information returned in step 4 ends with a ".", then set (COMPL-KNOW = TRUE). B. Manning (Rice University) [Page 6] INTERNET-DRAFT DNS NSAP RRs 26 Nov, 1992 7.go to step 3. The a priori knowledge required is that all NSAPs begin with an initial one-octet field, the AFI (Authority and Format Identifier, see [ISO8348Ad2]); this is captured in step 1. Steps 3 through 7 represent a simple learning algorithm in which the resolver issues queries that are increasingly detailed until the result is obtained. Successful termination, step 4, occures if the last query sent was based on complete NSAP structure information, as determined by the trailing ".". 7 Examples Three examples are presented. The first uses US GOSIP NSAPs, the second a fictitious NSAP structure based on the idea of an Internet-assigned AFI, and the third demonstrates the scheme in the presence of a variable-length NSAP field. ;;;;;; ;;;;;; GOSIP-style NSAP. ;;;;;; . IN NSAP 47 . IN NSAP 47.0005 . IN NSAP 47.0005.80 nist.gov IN NSAP 47.0005.80.005a00 emu.ncsl.nist.gov IN NSAP ( 47.0005.80.005a00.0000.1000.0020.00800a123456.01) 47 IN NSAP-PTR . 2 0500.47 IN NSAP-PTR . 1 80.0500.47 IN NSAP-PTR . 3.2.2.2.6.1. 005a00.80.0500.47 IN NSAP-PTR nist.gov 2.2.2.6.1. 01.5634120a8000.2000.0010.0000.005a00.80.0500.47 IN NSAP-PTR emu.ncsl.nist.gov .) ;;;;;; ;;;;;; Internet AFI-based NSAP. ;;;;;; ; B. Manning (Rice University) [Page 7] INTERNET-DRAFT DNS NSAP RRs 26 Nov, 1992 ; Assume XX is the Internet AFI, and XX-based NSAPs have ; a fixed 19-byte format: ; 1.1.3.3.4.6.1. ; where the numbers indicate field sizes in octets. ; . IN NSAP XX . IN NSAP XX.12 bb IN NSAP XX.12.123456 reg.bb IN NSAP XX.12.123456.151617 host.reg.bb IN NSAP ( XX.12.123456.151617.37383930.414243454647.89) XX IN NSAP-PTR . 1.3.3.4.6.1. 12.XX IN NSAP-PTR . 3.3.4.6.1. 563412.12.XX IN NSAP-PTR bb 3.4.6.1. 171615.563412.12.XX IN NSAP-PTR reg.bb 4.6.1. 89.474645434241.30393837.171615.563412.12.XX ( IN NSAP-PTR host.reg.bb .) ;;;;;; ;;;;;; NSAP with variable-size field. ;;;;;; ; ; An example of an NSAP format with a variable field size. ; The example is of an X.121 NSAP. ; . IN NSAP 37 one-org.com IN NSAP 37.31342023011007.01 two-org.com IN NSAP 37.575654012456.03 37 IN NSAP-PTR com *.1. 01.07100123203431.37 IN NSAP-PTR one-org.com . 03.562401545657.37 IN NSAP-PTR two-org.com . B. Manning (Rice University) [Page 8] INTERNET-DRAFT DNS NSAP RRs 26 Nov, 1992 8 Security Security issues are not addressed in this memo. 9 References [1] ISO/IEC, "Protocol for Providing the Connectionless-mode Network Service" USC/Information Sciences Institute, September 1981. [2] Reynolds, J., J. Postel, "Assigned Numbers", RFC 1340, USC/Information Sciences Institute, July, 1992. 10 Authors' Addresses Bill Manning Rice University - ONCS P.O. Box 1892 6100 South Main Houston, Texas 77251-1892 USA Phone: +1.713.285.5415 EMail: bmanning@rice.edu Richard Colella National Institute of Standards and Technology Technology/B217 Gaithersburg, MD 20899 USA Phone: +1 301-975-3627 (voice); +1 301 590-0932 (fax) EMail: colella@nist.gov (Internet) /C=us/A=attmail/P=gov+nist-gw/S=colella/ (X.400) A Issues A.1 User Interfaces Typical user interfaces, for example nslookup, expect the inverse map string to be typed from least significant byte to most significant byte followed by IN-ADDR.ARPA. This isn't too bad for four-byte IP addresses, but can be excruciating for 20-byte NSAPs. It would be much easier if this reversal could be done by the software instead of the user. This is especially true since one convenient way to handle NSAPs is by picking and stuffing values. So, if we have an NSAP, 47000580005a0000001000002000800a12345601 B. Manning (Rice University) [Page 9] INTERNET-DRAFT DNS NSAP RRs 26 Nov, 1992 One would like to pick it, stuff it on a command line (e.g., to nslookup), and append NSAP-PTR.ARPA.: % nslookup 47000580005a0000001000002000800a12345601.NSAP-PTR.ARPA. The resolver code could recognize the NSAP-PTR.ARPA domain and perform the appropriate reversal before issuing the query. A.4 Relationship to X.500 It may be useful to associate an X.500 distinguished name with an NSAP. Some thought should be given to whether this is useful and how it could be done. A.5 NSAP prefixes Should NSAP prefixes be encoded in the DNS? This may have some useful features. Expiration: April 14, 1993 [Page 10] B. Manning (Rice University) [Page 10] -- Regards, Bill Manning bmanning@rice.edu PO Box 1892 713-285-5415 713-527-6099 Houston, Texas R.U. (o-kome) 77251-1892